Release Notes JavaTM 2 SDK, Standard Edition Version 1.4.0 Release Candidate

Contents

Overview
Networking
AWT
Java 2D^TM Technology
Drag and Drop
Internationalization
Accessibility
CORBA, Java IDL, and Java RMI-IIOP
Virtual Machines
New I/O (NIO) APIs
Java Platform Debugger Architecture Technology
Java Web Start
Java Plug-in Technology on Netscape^TM 6.1 and 6.2 Browsers
Comformance on Solaris with OpenWindows
Platform Time Zone Detection on Microsoft Windows
Applet Class Bug
Linux Notes
Active X Bridge Removed
Forte for Java and NetBeans
Tools and Utilities
Jar File Changes

The Java^TM 2 SDK, Standard Edition, v1.4.0 (J2SDK 1.4.0) is an upgrade release of the Java platform containing new features and enhancements in many functional areas. The new features in J2SDK 1.4.0 are being developed in accordance with the Java Community Process^SM program.

 

For information on known bugs and other issues in the networking functionality of this release, see Networking Release Notes.

The following notes pertain to AWT functionality in this release.

• If you have installed English Visual C++ 6.0 onto a machine that also has an Asian edition of Windows NT installed, you may encounter strange artifacts when rendering Asian text in a TextArea component. You may also see this problem if you have installed Microsoft Exchange or Microsoft Office 97 onto a machine running an Asian Windows NT 4.0. Although this problem was reported on the Japanese version of Windows NT, it will probably occur on other non-Latin versions of NT as well, such as Chinese or Korean.

  The problem is caused when the installation of those programs replaces the Asian Riched32.dll file with the English version of the same file. The problem can be corrected by replacing Riched32.dll with the Asian version.

• A bug in the AWT Robot class can cause the Java virtual machine to crash with an EXCEPTION_ACCESS_VIOLATION in some situations when the -Xfuture flag is used on Microsoft Windows platforms. To avoid this problem, run without the -Xfuture flag. This problem will be fixed in the final release of the J2SE 1.4.0 platform.

The following notes pertain to Java 2D functionality in this release.

• It is now possible to access hardware acceleration for image scaling on win32 platforms. However, due to reasons of rendering quality and consistency, this feature is disabled by default. For users who think they can benefit from this performance improvement and want to experiment with the results in their application, the feature can be enabled with the runtime flag sun.java2d.ddscale=true. For example, an application would be run as follows to enable hardware-accelerated scaling:

  	java -Dsun.java2d.ddscale=true 
  

• The outline returned by GlyphVector.getGlyphOutline and the bounds returned by GlyphVector.getGlyphVisualBounds are positioned differently in this release. Prior to this release, the outline and the bounds were positioned around the point (0, 0). For this release, the outline and bounds are positioned around the origin of each individual glyph. This semantic change was made to make the results consistent with the behavior of GlyphVector.getGlyphLogicalBounds.

• A High Performance Graphics white paper is available online.

The following notes pertain to drag-and-drop functionality in this release.

• In the Solaris and Linux releases of Java 2 Standard Edition, SDK 1.3, several of the AWT heavyweight Components exhibited default drag behavior via the middle mouse button, even if the application did not identify these Components as DragSources via the java.awt.dnd API. These Components were implemented using Motif peers, and Motif provides middle button drag behavior for these peers by default.

  Because of the design of the AWT, and because of bugs in the Motif library, this default behavior has been the source of numerous stability problems. Rather than continue to risk the stability of AWT and Drag & Drop for a niche feature, we have chosen to disable this feature explicitly in our implementations.

  Developers can still identify these Components as DragSources in their applications using the java.awt.dnd API. This is both functional and supported.

  This approach is superior to relying upon default Motif behavior in any case, because it enables drag support for these Components on all platforms, not just Solaris and Linux.

• A change in Drag&Drop behavior was introduced in J2SE 1.3.1 as part of the fix for bug 4313374. The changed behavior is also part of J2SE 1.4.0. In the new behavior, drag operations are blocked until any previous Drag&Drop operation is completed. Prior to J2SE 1.3.1, drag operations could be initiated even if another drag-and-drop operation was currently in progress.

  A well-constructed application will call either DropTargetDropEvent.rejectDrop(), or both DropTargetDropEvent.acceptDrop(int) and DropTargetDropEvent.dropComplete(boolean) inside DropTargetListener.drop(DropTargetDropEvent). This will terminate the current Drag&Drop operation before the Drag&Drop subsystem can recognize and initiate another. Therefore, this change in behavior should only affect incorrectly written applications.

Currency for European Monetary Union - The default currency used by the java.text.NumberFormat, DecimalFormat, and DecimalFormatSymbol classes for the member countries of the European Monetary Union changes to the Euro for all instances created after 1/1/2002, 0:00 local time of the respective countries. Applications can use new API on these classes and the new java.util.Currency class to specify the currency used. See Request-for-Enhancements 4311107 and 4290801.

A new method, "createInputMethodJFrame", has been added to the java.awt.im.spi.InputMethodContext interface to provide Java input methods with Swing based input method windows. Adding a new method to an existing interface usually breaks the upward binary compatibility, but as the java.awt.im.spi.InputMethodContext interface is implemented only by the JRE, there is no compatibility problem for existing Java applications. When writing new Java input methods based on the J2SDK  1.4.0, input method implementors are encouraged to use the reflection mechanism to call this method since it is not available in prior releases.

Method AccessibleJComboBox.getAccessibleSelection(int) works incorrectly in this release. It always returns null. This problem is being tracked as bug 4401715, and it will be fixed in the final release of the J2SE 1.4.0 platform.

Limitations for Java IDL and Java RMI-IIOP - For information on limitations regarding the use of Java IDL and Java RMI-IIOP, please read the document Limitations for Java IDL and Java RMI-IIOP.

The following notes pertain to the virtual machines in J2SDK 1.4.0.

• A bug in the T1 library of the Solaris operating environment causes the calling thread to hang when a call is made to libthread "T1" thr_suspend. This bug can affect applications running on the Java HotSpot VM in the Java 2 SDK. It is known to affect the ATG Dynamo application server and the Tomcat implementation of Java^TM Servlet and JavaServer Pages^TM technologies. This problem is being tracked in bug 4511519.
  A possible workaround to launch applications with the -XX:-UseLWPSynchronization command-line flag. However, this workaround has not been extensively tested. On Solaris 8, use new the new T2 libthread as a workaround. Under Solaris 8 set LD_LIBRARY_PATH=/usr/lib/lwp. Under Solaris 9 this workaround is not neccessary because new libthread is the default.

• Beginning with J2SDK 1.4.0, the Classic Virtual Machine is no longer shipped as part of the Java 2 SDK. (On Solaris platforms, the Classic VM was removed in J2SDK 1.3.0.) If you have been running your applications on the Classic VM by using the -classic command-line option, you will need to use either the Java HotSpot Client VM (invoked by default or by using the -client option) or Java HotSpot Server VM (invoked with the -server option). Attempting to launch an application with the -classic option will result in this message: Error: Classic VM no longer supported.

• The J2SE 1.4.0 platform accepts class file versions in the range 45.3 to 48.0.

These notable NIO bugs exists in this release:

• Asynchronous closing and interruption do not work on Linux (bug 4460583).
• Interruption of file-locking operations not completely implemented (bug 4460065).
• Large files broken on Linux (both java.io and java.nio) (bug 4430625).
• Key-cancellation mechanism has race conditions (bug 4458268).
• Selector only supports 63 channels on the Microsoft Windows operating system (bug 4503092).

For information about NIO, see the main and supplemental NIO documentation.

Java Platform Debugger Architecture Technology

The following problems pertain to the HotSwap functionality of the Java Platform Debugger Architecture technology.

• Line numbers are not updated after a redefineClass operation. This means that ReferenceType.allLineLocations() will not return the correct line numbers for the redefined class, and problems such as "invalid code index" errors may result. This problem is being tracked as bug 4531511.

• In most cases, the VM will crash when a method in a redefined class throws an exception. Another characteristic of this problem when using the Java HotSpot Client VM on Microsoft Windows platforms is that the VM will crash when one redefined method returns to another redefined method. This part of the problem can be avoided by having on the stack no more than one method of a class being redefined. See bug 4559100.

The following notes pertain to Java Web Start 1.0.1_02, which is included in J2SE 1.4.0.

• The Java Web Start security warning dialog box can cause Java Web Start and the application to hang. This problem is due to a bug in the implementation of event dispatching notification. This problem is being tracked in bug report 4486581 (currently not on the Bug Parade web site).

• When Java Web Start 1.0.1_02 is used to open an unsigned application, the message "Java Web Start Window" will appear in an inset in the application's window. On Microsoft Windows platforms, the message will be at the bottom of the application window. On the Solaris operating environment and on Linux, the message will be near the top of the application window, just below the window's title bar.

• In Java Web Start 1.0.1_02, the Java Network Launching Protocol (JNLP) will not allow use of any settings of the form <property name="NAME" value="VALUE"/> unless the "NAME" begins with "jnlp." or "javaws."

The regxpcom functionality of Netscape 6.1 and 6.2 browsers has a bug that affects the registering of the Java Plug-in product. (See Bugzilla bug 112201.) Regxpcom may not finish until a reboot (on version 6.1 browsers) or it may crash (on version 6.2 browsers). One possible symptom of this bug: Users of Netscape 6.1 browsers who try to configure the Java Plug-in control panel to use Netscape 6 will find that Netscape 6 is never registered. This may lead the users to repeatedly select Netscape 6 in the control panel which will only start multiple regxpcom processes running endlessly in the background, using up the CPU. This problem is fixed in version 6.2.1 of the Netscape browser.

When running J2SE 1.4.0 on the Solaris operating environment, behavior in conformance with the Java 2 Platform specification is not guaranteed when using OpenWindows. In particular, some APIs related to handling focus, such as the Component.requestFocus() method, fail when using OpenWindows. This problem is due to a bug in OpenWindows. See the bug description for 4505899 for more information.

This bug does not exist in the CDE window manager.

If you select a time zone that doesn't observe daylight saving time (e.g., Tokyo Standard Time) on installation of a Microsoft Windows operating system, that selection may turn off the global system setting "Automatically adjust clock for daylight saving changes." Under this setting, the Java runtime detects the platform time zone in the GMT offset format (e.g., "GMT+09:00"), not as a time zone ID (e.g., "Asia/Tokyo"). To fix this installation problem, take the following steps after the installation (unless you intend to turn off the setting):

1. Open Date/Time in Control Panel.
2. On the Time Zone tab, choose a time zone that observes daylight saving time (e.g., "(GMT-08:00) Pacific Time (US & Canada); Tijuana"), select the "Automatically adjust clock for daylight saving changes" check box, and press the Apply button.
3. Choose your time zone back and press the OK button.

Method java.applet.getDocumentBase() is supposed to return the absolute URL of the directory of the document containing the applet. Method java.applet.getCodeBase() is supposed to return the URL of the applet itself. In the Java 2 SDK, the behavior of these two methods is reversed. This problem is being tracked as bug 4456393.

Linux Notes

Behavior in comformance with the API specification is not guaranteed while running as superuser on any version of Linux whose kernel was compiled with the CONFIG_IP_TRANSPARENT_PROXY option. The default kernel shipped with the RedHat 6.2 distribution is compiled with this option. To avoid incompatibilities associated with this problem, either do not use the Java platform while superuser or else upgrade to a Linux operating system whose kernel was not compiled with the CONFIG_IP_TRANSPARENT_PROXY option. Red Hat 7.1 ships with the version 2.4 kernel which does not have this problem.

Active X Bridge Removed

The Active X Bridge has been removed in J2SE 1.4.0.

Forte for Java 3.0 and NetBeans 3.2.1 will work in conjunction with J2SE 1.4.0. However, Forte for Java 2.0 and NetBeans 3.2 do not work with J2SE 1.4.0.

Tools and Utilities

The following notes pertain to the tools and utilities in this release.

• The 1.4 release introduces a new launcher mechanism to replace the earlier shell scripts. This change should be transparent when running existing java applications. However when debugging using the gdb debug tool on Linux, the launcher requires the LD_LIBRARY_PATH environment variable to be set to the specific configuration shown below; you can append your own LD_LIBRARY_PATH paths to the end of this list.

  LD_LIBRARY_PATH=/usr/java/j2sdk1.4.0/jre/lib/i386/client: \
  /usr/java/j2sdk1.4.0/jre/lib/i386:/usr/java/j2sdk1.4.0/jre/../lib/i386
  

  The /usr/java/j2sdk1.4.0 path is the default 1.4 installation directory. This issue is covered by bug report 4526137.

• The following obsolete tools and utilities have been removed from J2SE 1.4:
  • oldjava and oldjavaw
  • oldjavac
  • javald

• 4083890: The javac compiler now correctly detects unreachable null statements, as in the second semicolon in the following example:

  void someMethod(){
      return;;
  } 
  

• Javadoc tool - New features and bug fixes are documented at What's New in Javadoc 1.4. The following list includes both major outstanding 1.4.0 bugs and all known regressions (features that work in 1.3.1 but are broken in 1.4.0). For all bugs, see What Bugs are in Javadoc?
  • {@inheritDoc} tag is broken - It does not inherit the doc comment. There is no workaround. See Bug 4618686

  • Interface constants are missing from the Constant Field Values list Bug 4526070

  • Indentation for comments omitting the leading asterisk (*) is indented one extra space in the HTML output. Bug 4587562

  • {@docRoot} tag is broken - It interprets to a value with a mistaken trailing slash (/). In previous releases it included no trailing slash. This extra slash causes the URL to be broken if there was already a slash following {@docRoot}. The workaround is for you to remove any slash immediately following {@docRoot} from the doc comment. The mistaken extra slash will be removed in a future release. While all links from {@docRoot} have an extra slash, both Netscape and Internet Explorer are forgiving (go to the correct page) when the extra slash is followed by a directory or file name:

            <a href="../../..//serialized-form.html#javax.rmi.CORBA.Stub">
    

    but not forgiving when followed by dots:

            <a href="../..//../guide/misc/threadPrimitiveDeprecation.html">
    

    The former occurs when linking to pages under the doc root (the root of the api docs), while the latter occurs when linking to pages outside the api doc hierarchy. Therefore, broken links are noticed only when linking outside the api doc hierarchy. A workaround is to post-process the files and remove the extra slashes. See Bug 4524350

  • The class "Use" pages are missing methods that return the class or accept the class type as an argument. This makes the "Use" pages much less useful. Bug 4496290

  • A hard-coded anchor tag <A HREF="xx">YY</A> located in the first sentence of a class comment may be truncated when it appears on the package-summary.html page. Because the truncation occurs before the trailing quote ("), it can swallow the following text. No known workaround except to post-process the file. Bug 4523891

  • When passing package names into Javadoc, it mistakenly documents any .class files (belonging to the specified packages) that it encounters on classpath. It did not do this in previous releases. Because the source file doc comments are not available, these classes are documented with no comments. Workarounds: Change classpath to omit the path to the .class files, or pass in source filenames rather than package names. Bug 4548768

  • Links to external methods using -link or -linkoffline are not generated. No known workaround. Bug 4615751

  • Javadoc cannot document packages named *.java, such as com.ibm.java. Workaround is to pass in the class names rather than package names. Bug 4507380

  • Within a method, after an @throws tag for a given exception, Javadoc ignores additional @throws tags for the same exception. Bug 4525364

  • Links to "Serialized Form" mistakenly no longer contain anchors to classes. Bug 4521661

• A limitation in the 1.x versions of the libsafe library, available from Avaya Labs Research, can cause Java 2 SDK tools to fail with the message "Invalid initial heap size: -Xms8m." Trying to use the java application launcher by setting the -Xms option explicitly will fail also. This limitation is fixed in the most recent release of the libsafe library, version 2.0, available for download from http://www.research.avayalabs.com/project/libsafe/.

File rt.jar no longer contains directory entries such as java/ and java/io/. It contains only entries for actual class files, such as java/io/InputStream.class. Likewise, file charsets.jar no longer contains directory entries.